Enhanced destination information for rideshare service

ABSTRACT

The present disclosure provides a method comprising receiving a ride request from a user having a user profile, the ride request including a requested drop-off location within a service area and the user profile specifying at least one drop-off location preference parameter; querying a database to obtain data regarding a condition of the requested drop-off location, wherein the data is collected by a plurality of vehicles traversing the service area and equipped with at least one sensor and at least one imaging device; determining whether the obtained data satisfies the at least one drop-off location preference parameter; and determining at least one alternative drop-off location within a first distance from the requested drop-off location if the obtained data does not satisfy the at least one drop-off location preference parameter.

TECHNICAL FIELD OF THE DISCLOSURE

The present disclosure relates generally to rideshare services and, morespecifically, to devices and methods for enabling delivery of enhancedinformation about a selected destination to a rideshare service user.

BACKGROUND

Rideshare service users may benefit from access to real time informationregarding their destination, such as the weather, pedestrian density,lighting conditions, accessibility, etc., prior to selecting and/orconfirming a specific drop-off point at the destination. Access to andprovision of such information would enable users to better plan fortheir trip or to modify their selected drop-off point.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 is a block diagram illustrating an example autonomous vehicle(AV) in which an enhanced destination information system (EDIS)according to some embodiments of the present disclosure may beimplemented;

FIG. 2 is a block diagram illustrating an example EDIS according to someembodiments of the present disclosure;

FIG. 3 is a flowchart of an example method of using the EDIS of FIG. 2to set up EDIS preferences according to some embodiments of the presentdisclosure;

FIG. 4 is a flowchart of an example method implemented by the EDIS ofFIG. 2 for accumulating real time fleet information (RTFI) regarding arequested destination according to some embodiments of the presentdisclosure; and

FIG. 5 is a flowchart of an example method implemented by the EDIS ofFIG. 2 for utilizing RTFI stored in a database in connection with a riderequested by a user according to some embodiments of the presentdisclosure.

DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE DISCLOSURE

The systems, methods and devices of this disclosure each have severalinnovative aspects, no single one of which is solely responsible for allof the desirable attributes disclosed herein. Details of one or moreimplementations of the subject matter described in this specificationare set forth in the description below and the accompanying drawings.

In many instances, rideshare service users may benefit from access toreal time information regarding their intended destination, such asweather and related conditions, pedestrian density, lighting conditions,accessibility, etc., prior to selecting and/or confirming a specificdrop-off point at the destination. Access to and provision of suchinformation would enable users to better plan for their trip or tomodify their selected drop-off point.

For example, a user may prefer to avoid large crowds, to avoid beingdropped off after dark in a location that does not have operationalstreetlamps or other forms of artificial lighting, to avoid windylocations, or to avoid locations that are inconvenient or inaccessibledue to physical limitations of the user.

In accordance with features of embodiments described herein, a rideshareuser may opt in to a service for providing enhanced destinationinformation (“Enhanced Destination Information Service” or “EDIS”) bymaking appropriate selections in the user's profile maintained with therideshare service provider to indicate the user's preferences. Forexample, the user may select conditions of interest (e.g., pedestriandensity, lighting conditions) individually or may select all availableconditions as conditions of interest. Additionally, within each selectedcondition, the user may specify thresholds or ranges of interest for thecondition (e.g., a maximum level for pedestrian density that is not tobe exceeded or a minimum level of lighting that must be exceeded duringa range of hours). The user may further indicate a maximum distance froma selected drop-off point to be used in cases in which the selecteddrop-off point needs to be modified (as described below). Once theconditions and associated ranges/thresholds have been selected, the usermay further select (either individually for each selected condition orcollectively for all conditions) whether s/he would prefer to be alertedconcerning existence of those conditions at the selected drop-off point,have her/his selected drop-off point automatically modified inaccordance with her/his preferences, or both.

In accordance with features of embodiments described herein, as vehiclesthat make up the rideshare service provider's fleet (which in someembodiments may comprise one or more autonomous vehicles (AVs) drivethrough a service area, the vehicles collect visual images of theirenvironment using the exterior cameras, as well as a variety of othertypes of information using other types of sensors with which the vehicleis fitted. The collected information is timestamped and location taggedand then may be sent to a remote computer to be post-processed todetermine information such as pedestrian density in a scene. Thepost-processed information is stored in a real-time fleet information(RTFI) database.

In an example operation, when a user requests a ride to a destinationand specifies a drop-off point, the RTFI database is queried todetermine when a vehicle from the rideshare service fleet last drove bythat location or in the vicinity of the location (depending on theinformation to be acquired per the user's profile settings). Theresulting information is consolidated to be provided to the user and/orused to modify the drop-off point. For example, if a user requested tobe dropped off at Ocean Beach, the following information may be sent tothe user: “5 minutes ago at this location it was sunny, withapproximately 100 pedestrians in view. An image is attached.” Based onthe user-selected preferences, alternative drop-off points could also berecommended. For example, if the user indicated s/he preferred to avoidcrowds, the vehicle RTFI database to determine whether there was analternate drop-off point near the requested one that had a lowerpedestrian density at the time. This concept could be extended toprovide updates during the ride. In particular, if during the ride,conditions at the originally selected drop-off point changes such thatthey no longer comply the user's preferences, the user couldautomatically be rerouted to or prompted to select a new drop-off pointnear the originally selected drop-off point that complies with thepreferences the user specified in her/his profile. For example, if oncethe drop-off point is selected and the ride has commenced, thepopulation density has increased to above a maximum threshold levelspecified by the user, the user may be provided with a list ofalternative drop-off locations near the originally selected locationthat comply with the population density limitations.

As will be appreciated by one skilled in the art, aspects of the presentdisclosure described herein may be embodied in various manners (e.g., asa method, a system, a computer program product, or a computer-readablestorage medium). Accordingly, aspects of the present disclosure may takethe form of an entirely hardware embodiment, an entirely softwareembodiment (including firmware, resident software, micro-code, etc.) oran embodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Functions described in this disclosure may be implemented as analgorithm executed by one or more hardware processing units, e.g. one ormore microprocessors, of one or more computers. In various embodiments,different steps and portions of the steps of each of the methodsdescribed herein may be performed by different processing units.Furthermore, aspects of the present disclosure may take the form of acomputer program product embodied in one or more computer readablemedium(s), preferably non-transitory, having computer readable programcode embodied, e.g., stored, thereon. In various embodiments, such acomputer program may, for example, be downloaded (updated) to theexisting devices and systems (e.g. to the existing system devices and/ortheir controllers, etc.) or be stored upon manufacturing of thesedevices and systems.

The following detailed description presents various descriptions ofspecific certain embodiments. However, the innovations described hereincan be embodied in a multitude of different ways, for example, asdefined and covered by the claims and/or select examples. In thefollowing description, reference is made to the drawings in which likereference numerals can indicate identical or functionally similarelements. It will be understood that elements illustrated in thedrawings are not necessarily drawn to scale. Moreover, it will beunderstood that certain embodiments can include more elements thanillustrated in a drawing and/or a subset of the elements illustrated ina drawing. Further, some embodiments can incorporate any suitablecombination of features from two or more drawings.

The following disclosure describes various illustrative embodiments andexamples for implementing the features and functionality of the presentdisclosure. While particular components, arrangements, and/or featuresare described below in connection with various example embodiments,these are merely examples used to simplify the present disclosure andare not intended to be limiting. It will of course be appreciated thatin the development of any actual embodiment, numerousimplementation-specific decisions must be made to achieve thedeveloper's specific goals, including compliance with system, business,and/or legal constraints, which may vary from one implementation toanother. Moreover, it will be appreciated that, while such a developmenteffort might be complex and time-consuming; it would nevertheless be aroutine undertaking for those of ordinary skill in the art having thebenefit of this disclosure.

In the Specification, reference may be made to the spatial relationshipsbetween various components and to the spatial orientation of variousaspects of components as depicted in the attached drawings. However, aswill be recognized by those skilled in the art after a complete readingof the present disclosure, the devices, components, members,apparatuses, etc. described herein may be positioned in any desiredorientation. Thus, the use of terms such as “above”, “below”, “upper”,“lower”, “top”, “bottom”, or other similar terms to describe a spatialrelationship between various components or to describe the spatialorientation of aspects of such components, should be understood todescribe a relative relationship between the components or a spatialorientation of aspects of such components, respectively, as thecomponents described herein may be oriented in any desired direction.When used to describe a range of dimensions or other characteristics(e.g., time, pressure, temperature, length, width, etc.) of an element,operations, and/or conditions, the phrase “between X and Y” represents arange that includes X and Y.

Other features and advantages of the disclosure will be apparent fromthe following description and the claims.

As shown in FIG. 1 , a system 100 embodying features described hereinincludes an autonomous vehicle 110 including a passenger interface 120,a vehicle coordinator 130, and/or a remote expert interface 140. Incertain embodiments, the remote expert interface 140 allows anon-passenger entity to set and/or modify the behavior settings of theautonomous vehicle 110. The non-passenger entity may be different fromthe vehicle coordinator 130, which may be a server.

A remote facility 160, which may comprise a central office or backofficefacility, may also be provided for providing the autonomous vehicle 110(and particularly, the onboard computer 145) with a number of differentsystem backend functions. The remote facility 160 may include one ormore switches, servers, databases, live advisors, and/or an automatedvoice response system (“VRS”). Remote facility 160 may include any orall of the aforementioned components, which may be coupled to oneanother via a wired or wireless local area network (LAN). Remotefacility 160 may receive and transmit data via one or more appropriatedevices and network from and to the autonomous vehicle 110, such as bywireless systems, such as 882.11x, General Packet Radio Service (GPRS),and the like. A database at the remote facility 160 can store accountinformation such as subscriber authentication information, vehicleidentifiers, profile records, behavioral patterns, and other pertinentsubscriber information. The remote facility 160 may also include adatabase of roads, routes, locations, etc., comprising a service areapermitted for use by autonomous vehicle 110. The remote facility 160 maycommunicate with the autonomous vehicle 110 to provide route guidance inresponse to a request received from the vehicle.

For example, as will be described in greater detail below, the remotefacility 160 may receive and store destination data and images for usein implementing aspects of the EDIS described herein. Additionally,autonomous vehicles, such as the autonomous vehicle 110, may, in thecourse of determining a navigation route, receive instructions from theremote facility 160 regarding which roads or portions thereof, if any,are appropriate for use under certain circumstances, as well as whichdrop-off point should be used. Such instructions may be based in part oninformation received from the autonomous vehicle 110 or other autonomousvehicles regarding road and environmental conditions Accordingly, remotefacility 160 may receive information regarding theroads/routes/environmental conditions generally in real-time from one ormore vehicles comprising a rideshare service provider's fleet.

The system 100 functions to enable an autonomous vehicle 110 to modifyand/or set a driving behavior in response to parameters set by vehiclepassengers (e.g., via the passenger interface 120, which may include auser profile) and/or other interested parties (e.g., via the vehiclecoordinator 130 or remote expert interface 140). Driving behavior of anautonomous vehicle may be modified according to explicit input orfeedback (e.g., a passenger specifying a maximum speed or a relativecomfort level), implicit input or feedback (e.g., a passenger's heartrate), or any other suitable data or manner of communicating drivingbehavior preferences.

The autonomous vehicle 110 is preferably a fully autonomous automobile,but may additionally or alternatively be any semi-autonomous or fullyautonomous vehicle; e.g., a boat, an unmanned aerial vehicle, adriverless car, etc. Additionally, or alternatively, the autonomousvehicles may be vehicles that switch between a semi-autonomous state anda fully autonomous state and thus, some autonomous vehicles may haveattributes of both a semi-autonomous vehicle and a fully autonomousvehicle depending on the state of the vehicle.

The autonomous vehicle 110 preferably includes a throttle interface thatcontrols an engine throttle, motor speed (e.g., rotational speed ofelectric motor), or any other movement-enabling mechanism; a brakeinterface that controls brakes of the autonomous vehicle (or any othermovement-retarding mechanism); and a steering interface that controlssteering of the autonomous vehicle (e.g., by changing the angle ofwheels of the autonomous vehicle). The autonomous vehicle 110 mayadditionally or alternatively include interfaces for control of anyother vehicle functions; e.g., windshield wipers, headlights, turnindicators, air conditioning, etc.

In addition, the autonomous vehicle 110 preferably includes an onboardcomputer 145 and a sensor suite 150 (e.g., computer vision (“CV”)system, Light Detection and Ranging (LIDAR), Radio Detection and Ranging(RADAR), wheel speed sensors, Global Positioning System (GPS), cameras,and a variety of other sensors). The onboard computer 145 functions tocontrol the autonomous vehicle 110 and processes sensed data from thesensor suite 150 and/or other sensors in order to determine the state ofthe autonomous vehicle 110. Based upon the vehicle state and programmedinstructions, the onboard computer 145 preferably modifies or controlsdriving behavior of the autonomous vehicle 110.

Driving behavior may include any information relating to how anautonomous vehicle drives (e.g., actuates brakes, accelerator, steering)given a set of instructions (e.g., a route or plan). Driving behaviormay include a description of a controlled operation and movement of anautonomous vehicle and the manner in which the autonomous vehicleapplies traffic rules during one or more driving sessions. Drivingbehavior may additionally or alternatively include any information abouthow an autonomous vehicle calculates routes (e.g., prioritizing fastesttime vs. shortest distance), other autonomous vehicle actuation behavior(e.g., actuation of lights, windshield wipers, traction controlsettings, etc.) and/or how an autonomous vehicle responds toenvironmental stimulus (e.g., how an autonomous vehicle behaves if it israining, or if an animal jumps in front of the vehicle). Some examplesof elements that may contribute to driving behavior include accelerationconstraints, deceleration constraints, speed constraints, steeringconstraints, suspension settings, routing preferences (e.g., scenicroutes, faster routes, no highways), lighting preferences, actionprofiles (e.g., how a vehicle turns, changes lanes, or performs adriving maneuver), and action frequency constraints (e.g., how often avehicle changes lanes).

The onboard computer 145 functions to control the operations andfunctionality of the autonomous vehicles 110 and processes sensed datafrom the sensor suite 150 and/or other sensors in order to determinestates of the autonomous vehicles no. Based upon the vehicle state andprogrammed instructions, the onboard computer 145 preferably modifies orcontrols behavior of autonomous vehicles 110. The onboard computer 145is preferably a general-purpose computer adapted for input/output I/Ocommunication with vehicle control systems and sensor systems, but mayadditionally or alternatively be any suitable computing device. Theonboard computer 145 is preferably connected to the Internet via awireless connection (e.g., via a cellular data connection). Additionallyor alternatively, the onboard computer 145 may be coupled to any numberof wireless or wired communication systems.

The sensor suite 150 preferably includes localization and drivingsensors; e.g., photodetectors, cameras, RADAR, Sound Navigation andRanging (SONAR), LIDAR, GPS, inertial measurement units (IMUs),accelerometers, microphones, strain gauges, pressure monitors,barometers, thermometers, altimeters, etc.

In certain embodiments, information collected by autonomous vehicles,such as autonomous vehicle 110, may be provided to the remote facility160, which may establish a database or map of routes in a given area orregion where use of an autonomous driving system may be permitted.Information may be collected from vehicles in real-time, i.e., as thevehicle(s) traverses the route(s) in question. Information may beanalyzed by a central office of the remote facility 160 in real-time, oron a periodic basis. The information may be provided to vehiclescollectively in the area, e.g., by way of a central database or map. Forexample, vehicles may pull route information from the database/map todetermine appropriate route(s) for use of an autonomous driving systemin any manner that is convenient. In some examples, a vehicle telematicsunit may selectively communicate with the remote facility to determinewhether a route may be used with an autonomous driving system. Inaccordance with another aspect of the invention, there is provided asystem for communicating with a plurality of vehicles may include aplurality of telematics units installed into each of the vehicles. Thetelematics units are configured to collect route information as thevehicles are traveling along a vehicle route.

FIG. 2 is a block diagram illustrating an example system 200 that may beconfigured to implement at least portions of a EDIS for an autonomousvehicle, such as the autonomous vehicle 110, in accordance withembodiments described herein, and more particularly as shown in theFIGURES described hereinabove. Part or all of the EDIS 200 may beimplemented as a sensor suite, such as the sensor suite 150, and/or anonboard computer, such as onboard computer 145, and/or a remote system,such as remote facility 160. As shown in FIG. 2 , the EDIS 200 mayinclude at least one processor 202, e.g. a hardware processor 202,coupled to memory elements 204 through a system bus 206. As such, thesystem may store program code and/or data within memory elements 204.Further, the processor 202 may execute the program code accessed fromthe memory elements 204 via a system bus 206. In one aspect, the systemmay be implemented as a computer that is suitable for storing and/orexecuting program code (e.g., onboard computer 145). It should beappreciated, however, that the system 200 may be implemented in the formof any system including a processor and a memory that is capable ofperforming the functions described in this disclosure.

In some embodiments, the processor 202 can execute software or analgorithm to perform the activities as discussed in this specification;in particular, activities related to an EDIS for an autonomous vehiclein accordance with embodiments described herein. The processor 202 mayinclude any combination of hardware, software, or firmware providingprogrammable logic, including by way of non-limiting example amicroprocessor, a digital signal processor (DSP), a field-programmablegate array (FPGA), a programmable logic array (PLA), an integratedcircuit (IC), an application specific IC (ASIC), or a virtual machineprocessor. The processor 202 may be communicatively coupled to thememory element 204, for example in a direct-memory access (DMA)configuration, so that the processor 202 may read from or write to thememory elements 204.

In general, the memory elements 204 may include any suitable volatile ornon-volatile memory technology, including double data rate (DDR) randomaccess memory (RAM), synchronous RAM (SRAM), dynamic RAM (DRAM), flash,read-only memory (ROM), optical media, virtual memory regions, magneticor tape memory, or any other suitable technology. Unless specifiedotherwise, any of the memory elements discussed herein should beconstrued as being encompassed within the broad term “memory.” Theinformation being measured, processed, tracked or sent to or from any ofthe components of the system 200 could be provided in any database,register, control list, cache, or storage structure, all of which can bereferenced at any suitable timeframe. Any such storage options may beincluded within the broad term “memory” as used herein. Similarly, anyof the potential processing elements, modules, and machines describedherein should be construed as being encompassed within the broad term“processor.” Each of the elements shown in the present figures may alsoinclude suitable interfaces for receiving, transmitting, and/orotherwise communicating data or information in a network environment sothat they can communicate with, for example, a system having hardwaresimilar or identical to another one of these elements.

In certain example implementations, mechanisms for implementing an EDISfor an autonomous vehicle as outlined herein may be implemented by logicencoded in one or more tangible media, which may be inclusive ofnon-transitory media, e.g., embedded logic provided in an ASIC, in DSPinstructions, software (potentially inclusive of object code and sourcecode) to be executed by a processor, or other similar machine, etc. Insome of these instances, memory elements, such as e.g. the memoryelements 204 shown in FIG. 2 , can store data or information used forthe operations described herein. This includes the memory elements beingable to store software, logic, code, or processor instructions that areexecuted to carry out the activities described herein. A processor canexecute any type of instructions associated with the data or informationto achieve the operations detailed herein. In one example, theprocessors, such as e.g. the processor 202 shown in FIG. 2 , couldtransform an element or an article (e.g., data) from one state or thingto another state or thing. In another example, the activities outlinedherein may be implemented with fixed logic or programmable logic (e.g.,software/computer instructions executed by a processor) and the elementsidentified herein could be some type of a programmable processor,programmable digital logic (e.g., an FPGA, a DSP, an erasableprogrammable read-only memory (EPROM), an electrically erasableprogrammable read-only memory (EEPROM)) or an ASIC that includes digitallogic, software, code, electronic instructions, or any suitablecombination thereof.

The memory elements 204 may include one or more physical memory devicessuch as, for example, local memory 208 and one or more bulk storagedevices 210. The local memory may refer to RAM or other non-persistentmemory device(s) generally used during actual execution of the programcode. A bulk storage device may be implemented as a hard drive or otherpersistent data storage device. The processing system 200 may alsoinclude one or more cache memories (not shown) that provide temporarystorage of at least some program code in order to reduce the number oftimes program code must be retrieved from the bulk storage device 210during execution.

As shown in FIG. 2 , the memory elements 204 may store a real-time fleetinformation (RTFI) module 220 and a mapping data module 222. In variousembodiments, the modules 220, 222, may be stored in the local memory208, the one or more bulk storage devices 210, or apart from the localmemory and the bulk storage devices. It should be appreciated that thesystem 200 may further execute an operating system (not shown in FIG. 2) that can facilitate execution of the modules 220, 222. The modules220, 222, being implemented in the form of executable program codeand/or data, can be read from, written to, and/or executed by the system200, e.g., by the processor 202. Responsive to reading from, writing to,and/or executing one of the modules 220, 222, the system 200 may beconfigured to perform one or more operations or method steps describedherein.

Input/output (I/O) devices depicted as an input device 212 and an outputdevice 214, optionally, may be coupled to the system. Examples of inputdevices may include, but are not limited to, a keyboard, a pointingdevice such as a mouse, or the like. Examples of output devices mayinclude, but are not limited to, a monitor or a display, speakers, orthe like. In some implementations, the system may include a devicedriver (not shown) for the output device 214. Input and/or outputdevices 212, 214 may be coupled to the system 200 either directly orthrough intervening I/O controllers. Additionally, sensing devices 215,may be coupled to the system 200. Examples of sensing devices 215 mayinclude, but are not limited to, cameras (located inside and/or outsidethe vehicle), LIDARs, RADARS, scales, quick response (QR) code readers,bar code readers, radio frequency (RF) sensors, and others. Sensingdevices 215 may be coupled to the system 200 either directly or throughintervening controllers and/or drivers.

Cameras may be implemented using high-resolution imagers with fixedmounting and field of view. LIDARs may be implemented using scanningLIDARs with dynamically configurable field of view that provides apoint-cloud of the region intended to scan. RADARs may be implementedusing scanning RADARs with dynamically configurable field of view.

In an embodiment, the input and the output devices may be implemented asa combined input/output device (illustrated in FIG. 2 with a dashed linesurrounding the input device 212 and the output device 214). An exampleof such a combined device is a touch sensitive display, also sometimesreferred to as a “touch screen display” or simply “touch screen”. Insuch an embodiment, input to the device may be provided by a movement ofa physical object, such as e.g. a stylus or a finger of a user, on ornear the touch screen display.

A network adapter 216 may also, optionally, be coupled to the system 200to enable it to become coupled to other systems, computer systems,remote network devices, and/or remote storage devices throughintervening private or public networks. The network adapter may comprisea data receiver for receiving data that is transmitted by said systems,devices and/or networks to the system 200, and a data transmitter fortransmitting data from the system 200 to said systems, devices and/ornetworks. Modems, cable modems, and Ethernet cards are examples ofdifferent types of network adapter that may be used with the system 200.

FIG. 3 is a flowchart of an example method 300 of using an EDIS, such asthe EDIS 200 of FIG. 2 , according to some embodiments of the presentdisclosure. In particular, FIG. 3 illustrates a method of interactingwith a passenger interface 120, which may comprise a rideshareapplication (or rideshare app) that may be used to access a profile ofthe user via a mobile communications device, for example.

In step 302, a user opts in to the EDIS service; e.g., by selecting acorresponding option in her/his user profile.

In step 304, a variety of available EDIS parameters are presented to theuser (e.g., displayed via the passenger interface/user profile) forenabling the user to specify drop-off point condition preferences. Foreach of the presented parameters, the user may be provided with anopportunity to activate or deactivate the parameter. Moreover, for eachactivated parameter, the user may be provided with an opportunity tofurther refine the parameter (e.g., by specifying a threshold or otherlimiting factor for determining compliance of the drop-off pointcondition with the parameter), to specify whether the user would like tobe advised (e.g., via text or in-app messaging) of conditions of theselected drop-off point that do not comply with the parameter asoptionally refined (and in how much detail), and to specify whether, incases in which the conditions of the selected drop-off point do notcomply with the parameters as optionally refined, the user would likethe drop-off point to be automatically modified/changed or whether theuser would prefer to be provided with a list of options of alternativedrop-off points from which to select.

The user may also be provided with options that may be selected inconnection with single parameters or that may be applied globally, suchas whether conditions at the selected drop-off point should be monitoredthroughout the ride (with the drop-off point being modified oralternative options presented if at any point certain ones or all of theselected parameters are not complied with) or just at the point of riderequest, and a limit on the maximum distance between the originallyselected drop-off point and alternative drop-off points suggested ordeployed.

The parameters may also be selectively conditionally activated and/orrefined based on ride-specific factors, such as whether the user isalone (in which case, s/he may not want to be dropped off in a darklocation at night) or with others (in which case, s/he may not be asworried about the lighting conditions at the drop-off point at night),the time of day (e.g., rush hour vs. mid-afternoon; day vs. night), week(e.g., weekday vs. weekend), or year (e.g., summer vs. winter, holidayvs. non-holiday), a geographic location of the service area in which theuser is traveling (e.g., a large city vs. a rural area), weatherconditions (e.g., rainy vs. sunny), environmental conditions (e.g., snowon the ground vs. clear), or a combination of one or more of those, allof which is configurable by the user via the user's profile settings.The user may also be permitted to indicate a relative importance of theactivated parameters. For example, while both pedestrian density andaccessibility may both be important to a user, one may be more importantthan the other and the relative importance may have a direct impact onwhich of several drop off points would be more preferable to the user,all else being equal. Parameter settings may also be optionallyproactively suggested by the system based on demographics of thepassenger (e.g., a well-lit drop-off location may be suggested for ayoung, female passenger and a highly accessible drop-off location may besuggested for an elderly passenger).

It should be noted that the parameters presented to a user in step 304may include any environmental or other condition associated with apotential drop-off location that may be sensed or “seen” by a sensor orcamera (or camera-type) device and that may impact a user's desire to bedropped off at that location, including, but not limited to, weatherquality, air quality, lighting, traffic level, road quality (e.g.,existence of potholes that may be filled with water, steep incline,etc.), accessibility (e.g., proximity of curb ramps, sidewalks,construction in the area, etc.), noise (e.g., crowd noise, sirens,traffic noise, etc.), pedestrian density, time (e.g., time of year, timeof week, time of day), visibility (e.g., due to weather or lightingconditions), and so on.

In step 306, after the user has finished entering her/his EDISpreferences, the preferences are saved.

FIG. 4 is a flowchart of an example method 400 implemented by an EDIS,such as the EDIS 200 of FIG. 2 , for accumulating real time fleetinformation regarding a requested user destination according to someembodiments of the present disclosure.

In step 402, various types of sensor data and images are gathered by afleet of AVs during normal operation as the AVs move through a servicearea providing ride share services. In certain embodiments, one or moreAVs or other vehicles may be dispatched within the service areaspecifically to gather data. Images gathered by the AVs may include, forexample, images from cameras, CV, RADAR, and LIDAR and may depict theenvironment around the AV. Sensor information may include, for example,weather information (e.g., temperature, precipitation, wind) and ambientlighting conditions.

In step 404, the sensor data and images are time-stamped andlocation-tagged.

In an optional step 406, post-processing is performed on the sensor dataand/or images to determine additional information contained in thedata/images. For example, images may be further processed to determinepedestrian density at a location or to determine whether the location iswheelchair accessible. Post-processing of images may also be used todetermine lighting conditions at a location (e.g., are lights on or off)or an approximate percentage of pedestrians that are wearing masks orsunglasses, for example.

In step 408, the sensor data, images, and any additional informationacquired from post processing are stored in an RTFI database.

It will be recognized that the method 400 may preferably be executedcontinuously for each AV in the fleet while the AV is in service.

FIG. 5 is a flowchart of an example method 500 implemented by an EDIS,such as the EDIS 200 of FIG. 2 , for utilizing RTFI in connection with aride requested by a user according to some embodiments of the presentdisclosure.

In step 502, a user who has previously opted into the EDIS service(e.g., as illustrated in FIG. 3 ) requests a ride to a drop-offlocation.

In step 504, the RTFI database is queried for the most recent data andimages (e.g., based on data/image timestamps) regarding the requesteddrop-off location (e.g., based on data/image location tags).

In step 506, the data and images from the RTFI database obtained inresponse to the query are processed based on the EDIS preferencesspecified in the user's profile to determine their respective relevance.In particular, if the user has activated a “pedestrian density”parameter in her/his user profile, an image showing pedestrians in thearea of the designated destination would be considered relevant. Incontrast, if the user has not expressed a preference with regard topedestrian density, the image would be considered irrelevant.

In step 508, the relevant data and image(s) are consolidated into amessage containing the most recent information.

In step 510, a determination is made whether conditions at the drop-offlocation satisfy the user preferences as set forth in the user'sprofile. If not, execution proceeds to step 512.

In step 512, the RTFI database is queried for the most recent data andimages regarding one or more nearby, alternative drop-off locations. Itwill be recognized that what qualifies as an alternative drop-offlocation will be restricted by user preferences with regard to maximumallowable distance from the original drop-off location.

In step 514, a determination is made whether one of the alternativedrop-off location better satisfies the user's preferences as set forthin the user's profile. If so, execution proceeds to step 516.

In step 516, the user is provided with the message developed in step 508and the alternative drop-off location determined in step 514 isrecommended to the user. Alternatively, if more than one of thealternative drop-off locations are determined to better satisfy theuser's preferences in step 514, all of those alternatives may bepresented to the user in step 518.

In step 517, the user's response concerning drop-off location (originalor recommended alternative (or one of the recommended alternatives) isawaited.

If it is determined in step 514 that none of the alternative drop-offlocations better satisfies the user's preferences, execution proceeds tostep 518, in which the message developed in step 508 is provided to theuser. Alternatively, the user may be provided with an option to postponethe ride, cancel the ride, or expand the radius of acceptable drop-offlocations.

Similarly, if it is determined in step 510 that the original drop-offlocation does satisfy the user's preferences, execution also proceeds tostep 518, in which the message developed in step 508 is provided to theuser.

Upon completion of either of steps 517 or 518, execution proceeds tostep 520, in which the AV proceeds to the selected drop-off location(either original or alternative).

In an alternative embodiment, if a negative determination is made instep 514, the user may be additionally provided with the option tocancel or postpone the requested ride and/or to expand the radius ofacceptable alternative drop-off locations.

It will be recognized that steps 504-518 may be performed executed onlyprior to commencement of the ride or continuously throughout the ride,if that option has been enabled by the user. In the latter case, theconditions at the selected drop-off location will be continuallymonitored, with alternative drop-off locations being proposed if at anypoint, the user's preferences are not met by the current drop-offlocation.

In alternative embodiments, user preferences may be learned over time,with the system suggesting updates to EDIS preferences specified in theuser's profile as appropriate. Moreover, trend data associated with adrop-off location may be evaluated in addition to the most recent sensordata and images or may be evaluated instead of sensor data/images ifacceptably recent sensor data/images are available for any reason.

Example 1 is a method including receiving a ride request from a userhaving a user profile, the ride request including a requested drop-offlocation within a service area and the user profile specifying at leastone drop-off location preference parameter; querying a database toobtain data regarding a condition of the requested drop-off location,wherein the data is collected by a plurality of vehicles traversing theservice area and equipped with at least one of at least one sensor andat least one imaging device; determining whether the obtained datasatisfies the at least one drop-off location preference parameter; anddetermining at least one alternative drop-off location within a firstdistance from the requested drop-off location if the obtained data doesnot satisfy the at least one drop-off location preference parameter.

In Example 2, the method of Example 1 may further include dropping offthe user at the requested drop-off location if the obtained datasatisfies the at least one drop-off location preference parameter.

In Example 3, the method of any of Examples 1-2 may further include thefirst distance being specified by the user in the user profile.

In Example 4, the method of any of Examples 1-3 may further includeproviding the user with a message including information regarding thecondition of the requested drop-off location.

In Example 5, the method of any of Examples 1-4 may further includeproviding the user a recommendation regarding the at least onealternative drop-off location.

In Example 6, the method of any of Examples 1-5 may further includeprompting the user to select one of the requested drop-off location andthe at least one alternative drop-off location; and dropping the useroff at the selected one of the drop-off locations.

In Example 7, the method of any of Examples 1-6 may further includequerying the database to obtain data regarding a condition of the atleast one alternative drop-off location; determining whether theobtained data regarding the condition of the at least one alternativedrop-off location satisfies the at least one drop-off locationpreference parameter; and if the obtained data regarding the conditionof the at least one alternative drop-off location does not satisfy theat least one drop-off location preference parameter, prompting the userto select at least one of canceling the requested ride, postponing therequested ride, and increasing a value of the first distance.

In Example 8, the method of any of Examples 1-7 may further include thedrop-off location preference parameter indicating a user preference withregard to at least one of a noise level at the drop-off location, apedestrian density level at the drop-off location, accessibilityconditions at the drop-off location, road quality at the drop-offlocation, weather quality at the drop-off location, visibility at thedrop-off location, and lighting at the drop-off location.

In Example 9, the method of any of Examples 1-8 may further include apreference expressed by the drop-off location preference parameter beingdependent on at least one of time of day, time of week, and time ofyear.

In Example 10, the method of any of Examples 1-9 may further include apreference expressed by the drop-off location preference parameter beingdependent on a geographic location of the service area.

In Example 11, the method of any of Examples 1-10 may further include apreference expressed by the drop-off location preference parameter beingdependent on a number of passengers.

In Example 12, the method of any of Examples 1-11 may further include apreference expressed by the drop-off location preference parameter beinglearned over time.

In Example 13, the method of any of Examples 1-12 may further include apreference expressed by the drop-off location preference parameter beingset by the user.

In Example 14, the method of any of Examples 1-13 may further include apreference expressed by the drop-off location preference parameter beingbased on demographic information regarding the user.

Example 15 is a destination information system for a ride share service,the ride share service for transporting a user in response to receipt ofa ride request including a requested drop-off location, the destinationinformation system including a database for storing data collected by aplurality of vehicles traversing the service area and equipped with atleast one of at least one sensor and at least one imaging device forcollecting the data; and a real time fleet information (RTFI) moduleconfigured to, in receipt of the ride request query the database toobtain data regarding a condition of the requested drop-off location,wherein the data is collected by a plurality of vehicles traversing theservice area and equipped with at least one sensor and at least oneimaging device; determine whether the obtained data satisfies at leastone drop-off location preference parameter specified in a user profileassociated with the user in connection with the ride share service; anddetermine at least one alternative drop-off location within a firstdistance from the requested drop-off location if the obtained data doesnot satisfy the at least one drop-off location preference parameter.

In Example 16, the destination information system of Example 15 mayfurther include the RTFI module being further configured to provide theuser with a message including information regarding the condition of therequested drop-off location.

In Example 17, the destination information system of any of Examples15-16 may further include the RTFI module being further configured toprovide the user a recommendation regarding the at least one alternativedrop-off location; and prompt the user to select one of the requesteddrop-off location and the at least one alternative drop-off location.

In Example 18, the destination information system of any of Examples15-17 may further include the drop-off location preference parameterindicating a user preference with regard to a at least one of a noiselevel at the drop-off location, a pedestrian density level at thedrop-off location, accessibility conditions at the drop-off location,road quality at the drop-off location, weather quality at the drop-offlocation, environmental conditions at the drop-off location, visibilityat the drop-off location, and lighting at the drop-off location.

Example 19 is a method including accumulating data collected by aplurality of vehicles traversing a service area, wherein the datacomprises at least one of sensor data and image data generated byequipment associated with the vehicles; time stamping and locationtagging the accumulated data; post-processing the data to determineadditional information concerning a location with which the data isassociated; and storing the data and the additional information in adatabase; wherein in response to receipt of a ride request from a userhaving a user profile, the ride request including a requested drop-offlocation within the service area and the user profile specifying atleast one drop-off location preference parameter, the database isqueried to obtain a portion of the data concerning the requesteddrop-off location and a determination is made whether the obtainedportion of the data satisfies the at least one drop-off locationpreference parameter.

In Example 20, the method of Example 19 may further include, if theobtained portion of the data does not satisfy the at least one drop-offlocation preference parameter, at least one alternative drop-offlocation within a first distance from the requested drop-off locationbeing determined and suggested to the user.

It is to be understood that not necessarily all objects or advantagesmay be achieved in accordance with any particular embodiment describedherein. Thus, for example, those skilled in the art will recognize thatcertain embodiments may be configured to operate in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other objects or advantages as maybe taught or suggested herein.

In one example embodiment, any number of electrical circuits of theFIGS. may be implemented on a board of an associated electronic device.The board can be a general circuit board that can hold variouscomponents of the internal electronic system of the electronic deviceand, further, provide connectors for other peripherals. Morespecifically, the board can provide the electrical connections by whichthe other components of the system can communicate electrically. Anysuitable processors (inclusive of digital signal processors,microprocessors, supporting chipsets, etc.), computer-readablenon-transitory memory elements, etc. can be suitably coupled to theboard based on particular configuration needs, processing demands,computer designs, etc. Other components such as external storage,additional sensors, controllers for audio/video display, and peripheraldevices may be attached to the board as plug-in cards, via cables, orintegrated into the board itself. In various embodiments, thefunctionalities described herein may be implemented in emulation form assoftware or firmware running within one or more configurable (e.g.,programmable) elements arranged in a structure that supports thesefunctions. The software or firmware providing the emulation may beprovided on non-transitory computer-readable storage medium comprisinginstructions to allow a processor to carry out those functionalities.

In another example embodiment, the electrical circuits of the FIGS. maybe implemented as stand-alone modules (e.g., a device with associatedcomponents and circuitry configured to perform a specific application orfunction) or implemented as plug-in modules into application specifichardware of electronic devices. Note that particular embodiments of thepresent disclosure may be readily included in a system on chip (SOC)package, either in part, or in whole. An SOC represents an IC thatintegrates components of a computer or other electronic system into asingle chip. It may contain digital, analog, mixed-signal, and oftenradio frequency functions: all of which may be provided on a single chipsubstrate. Other embodiments may include a multi-chip-module (MCM), witha plurality of separate ICs located within a single electronic packageand configured to interact closely with each other through theelectronic package. In various other embodiments, the digital filtersmay be implemented in one or more silicon cores in Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), andother semiconductor chips.

It is also imperative to note that all of the specifications,dimensions, and relationships outlined herein (e.g., the number ofprocessors, logic operations, etc.) have only been offered for purposesof example and teaching only. Such information may be variedconsiderably without departing from the spirit of the presentdisclosure, or the scope of the appended claims. The specificationsapply only to one non-limiting example and, accordingly, they should beconstrued as such. In the foregoing description, example embodimentshave been described with reference to particular arrangements ofcomponents. Various modifications and changes may be made to suchembodiments without departing from the scope of the appended claims. Thedescription and drawings are, accordingly, to be regarded in anillustrative rather than in a restrictive sense.

Note that with the numerous examples provided herein, interaction may bedescribed in terms of two, three, four, or more electrical components.However, this has been done for purposes of clarity and example only. Itshould be appreciated that the system can be consolidated in anysuitable manner. Along similar design alternatives, any of theillustrated components, modules, and elements of the FIGS. may becombined in various possible configurations, all of which are clearlywithin the broad scope of this Specification. In certain cases, it maybe easier to describe one or more of the functionalities of a given setof flows by only referencing a limited number of electrical elements. Itshould be appreciated that the electrical circuits of the FIGS. and itsteachings are readily scalable and can accommodate a large number ofcomponents, as well as more complicated/sophisticated arrangements andconfigurations. Accordingly, the examples provided should not limit thescope or inhibit the broad teachings of the electrical circuits aspotentially applied to a myriad of other architectures.

Note that in this Specification, references to various features (e.g.,elements, structures, modules, components, steps, operations,characteristics, etc.) included in “one embodiment”, “exampleembodiment”, “an embodiment”, “another embodiment”, “some embodiments”,“various embodiments”, “other embodiments”, “alternative embodiment”,and the like are intended to mean that any such features are included inone or more embodiments of the present disclosure, but may or may notnecessarily be combined in the same embodiments.

It is also important to note that the functions related to contactlesscurrent measurement using magnetic sensors, e.g. those summarized in theone or more processes shown in FIGS., illustrate only some of thepossible functions that may be executed by, or within, the currentmeasurement systems illustrated in the FIGS. Some of these operationsmay be deleted or removed where appropriate, or these operations may bemodified or changed considerably without departing from the scope of thepresent disclosure. In addition, the timing of these operations may bealtered considerably. The preceding operational flows have been offeredfor purposes of example and discussion. Substantial flexibility isprovided by embodiments described herein in that any suitablearrangements, chronologies, configurations, and timing mechanisms may beprovided without departing from the teachings of the present disclosure.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims. Note that all optional featuresof the apparatus described above may also be implemented with respect tothe method or process described herein and specifics in the examples maybe used anywhere in one or more embodiments.

In order to assist the United States Patent and Trademark Office (USPTO)and, additionally, any readers of any patent issued on this applicationin interpreting the claims appended hereto, Applicant wishes to notethat the Applicant: (a) does not intend any of the appended claims toinvoke paragraph (f) of 35 U.S.C. Section 112 as it exists on the dateof the filing hereof unless the words “means for” or “step for” arespecifically used in the particular claims; and (b) does not intend, byany statement in the Specification, to limit this disclosure in any waythat is not otherwise reflected in the appended claims.

1-20. (canceled)
 21. A method comprising: accumulating data collected bya plurality of vehicles traversing a service area, wherein the datacomprises at least one of sensor data and image data generated byequipment associated with the vehicles; time stamping and locationtagging the accumulated data; post-processing the data to determineadditional information concerning a location with which the data isassociated; and storing the data and the additional information in adatabase; wherein in response to receipt of a ride request from a userhaving a user profile, the ride request including a requested drop-offlocation within the service area and the user profile specifying atleast one drop-off location preference parameter, the database isqueried to obtain a portion of the data concerning the requesteddrop-off location and a determination is made whether the obtainedportion of the data satisfies the at least one drop-off locationpreference parameter.
 22. The method of claim 21, wherein if theobtained portion of the data does not satisfy the at least one drop-offlocation preference parameter, at least one alternative drop-offlocation within a first distance from the requested drop-off location isdetermined and suggested to the user.
 23. The method of claim 21,wherein the equipment associated with the vehicles comprises at leastone of a camera, a light detection and ranging (LIDAR) sensor, and aradio detection and ranging (RADAR) sensor.
 24. The method of claim 21,wherein the at least one drop-off location preference parameterindicates a user preference with regard to at least one of a currentnoise level at the drop-off location, a current pedestrian density levelat the drop-off location, current weather conditions at the drop-offlocation, current visibility at the drop-off location, and currentlighting conditions at the drop-off location.
 25. The method of claim21, wherein a preference expressed by the at least one drop-off locationpreference parameter is dependent on at least one of time of day, timeof week, and time of year.
 26. The method of claim 21, wherein apreference expressed by the at least one drop-off location preferenceparameter is dependent on a geographic location of the service area. 27.The method of claim 21, wherein a preference expressed by the at leastone drop-off location preference parameter is dependent on a number ofpassengers.
 28. The method of claim 21, wherein a preference expressedby the at least one drop-off location preference parameter is learnedover time.
 29. The method of claim 21, wherein a preference expressed bythe at least one drop-off location preference parameter is set by theuser.
 30. The method of claim 21, wherein a preference expressed by theat least one drop-off location preference parameter is based ondemographic information regarding the user.
 31. One or morenon-transitory computer-readable storage media comprising instructionfor execution which, when executed by a processor, result in operationscomprising: accumulating data collected by a plurality of vehiclestraversing a service area, wherein the data comprises at least one ofsensor data and image data generated by equipment associated with thevehicles; time stamping and location tagging the accumulated data;post-processing the data to determine additional information concerninga location with which the data is associated; and storing the data andthe additional information in a database; wherein in response to receiptof a ride request from a user having a user profile, the ride requestincluding a requested drop-off location within the service area and theuser profile specifying at least one drop-off location preferenceparameter, the database is queried to obtain a portion of the dataconcerning the requested drop-off location and a determination is madewhether the obtained portion of the data satisfies the at least onedrop-off location preference parameter.
 32. The one or morenon-transitory computer-readable storage media of claim 31, wherein theoperations further comprise, if the obtained portion of the data doesnot satisfy the at least one drop-off location preference parameter:determining at least one alternative drop-off location within a firstdistance from the requested drop-off location; and suggesting the atleast one alternative drop-off location to the user.
 33. The one or morenon-transitory computer-readable storage media of claim 31, wherein theat least one drop-off location preference parameter indicates a userpreference with regard to at least one of a current noise level at thedrop-off location, a current pedestrian density level at the drop-offlocation, current weather conditions at the drop-off location, currentvisibility at the drop-off location, and current lighting conditions atthe drop-off location.
 34. The one or more non-transitorycomputer-readable storage media of claim 31, wherein a preferenceexpressed by the at least one drop-off location preference parameter isdependent on at least one of time of day, time of week, and time ofyear.
 35. The one or more non-transitory computer-readable storage mediaof claim 31, wherein a preference expressed by the at least one drop-offlocation preference parameter is dependent on a geographic location ofthe service area.
 36. A system comprising: a remote system foraccumulating data collected by a plurality of vehicles traversing aservice area, wherein the data comprises at least one of sensor data andimage data generated by equipment associated with the vehicles, theremote system further: time stamping and location tagging theaccumulated data; and post-processing the data to determine additionalinformation concerning a location with which the data is associated; anda database connected to the remote system for storing the data and theadditional information; wherein in response to receipt of a ride requestfrom a user having a user profile, the ride request including arequested drop-off location within the service area and the user profilespecifying at least one drop-off location preference parameter, theremote system queries the database to obtain a portion of the dataconcerning the requested drop-off location and determine whether theobtained portion of the data satisfies the at least one drop-offlocation preference parameter.
 37. The system of claim 36, wherein ifthe obtained portion of the data does not satisfy the at least onedrop-off location preference parameter, the remote system determines atleast one alternative drop-off location within a first distance from therequested drop-off location and suggests the at least one alternativedrop-off location to the user.
 38. The system of claim 36, wherein theequipment associated with the vehicles comprises at least one of acamera, a light detection and ranging (LIDAR) sensor, and a radiodetection and ranging (RADAR) sensor.
 39. The system of claim 36,wherein a preference expressed by the at least one drop-off locationpreference parameter is learned over time.
 40. The system of claim 36,wherein a preference expressed by the at least one drop-off locationpreference parameter is based on demographic information regarding theuser.